Issues in TCP Vegas

The Transmission Control Protocol (TCP) was first proposed and implemented to prevent the future congestion collapses after the congestion collapses in 1986. Since then, it has gone through several phases of improvement, and many new features such as fast retransmit and fast recovery have been added. Recently Brakmo et al. [2] have proposed a new version of TCP, which is named TCP Vegas, with a fundamentally different congestion avoidance scheme from that of TCP Reno and claimed that TCP Vegas achieves 37 to 71 percent higher throughput than TCP Reno. Ahn et al. [1] have evaluated the performance of TCP Vegas on their wide area emulator and shown that TCP Vegas does achieve higher efficiency than TCP Reno and causes much less packet retransmissions. However, they have observed that TCP Vegas when competing with other TCP Reno connections, does not receive a fair share of bandwidth, i.e., TCP Reno connections receive about 50 percent higher bandwidth. This incompatibility property is analyzed also by Mo et al. [6]. They show that due to the aggressive nature of TCP Reno, when the buffer sizes are large, TCP Vegas loses to TCP Reno that fills up the available buffer space, forcing TCP Vegas to back off. TCP Vegas has a few more problems that have not been discussed before, which could have a serious impact on the performance. One of the problems is the issue of rerouting. Since TCP Vegas uses an estimate of the propagation delay, baseRTT, to adjust its window size, it is very important for a TCP Vegas connection to be able to have an accurate estimation. Rerouting a path may change the propagation delay of the connection, and this could result in a substantial decrease in throughput. Another important issue is the stability of TCP Vegas. Since each TCP